Software Leadership #6: Read Every Checkin

February 12, 2014

One of the first questions I ask when joining a new team is: Where do code reviews happen?

The answer, and experience of joining in on such reviews, instantly tells you a lot about a team:

• Is there engineering rigor?
• How open is the team, e.g. is it more of a “closed team” or “everyone is welcome” kind of place?
• Does the team culture embrace technical debate and discussion?
• Who are the kickass programmers on the team?
• What is the work ethic of the team, e.g. do people checkin around the clock, including on weekends, or is it just 9-5?
• Related, is the team productive?
• What are we actually building, and how do developers spend their time? Are we moving in a consistent direction?
• Do people have their own comfort zones, or do developers collaborate across the whole codebase? What are the specific zones?
• How much energy is spent on writing new code, versus fixing existing code (bugs)?
• Is the environment more of a prototype and learn as you go one, or do checkins always come with buttoned up design specs?
• Do developers pay attention to things like performance when writing their code, e.g. do they often cite the results of measurements?
• How are our engineering tools, especially around code reviews and code sharing, and are they working well?
• How well do individuals communicate their ideas, e.g. are checkin notes terse and unintelligible, or articulate and thoughtful?

And so very much more.

As a technical leader and manager, code reviews and checkins are literally the heartbeat of your team. Reading them religiously – although admittedly time consuming – is an absolute requirement for truly understanding what the team is doing and its strengths and weaknesses. If you’re joining a new team, it puts you right at the heart of the engineering dialogue, and in a position to start fixing whatever is broken (opening it up, encouraging debate, changing technical direction, etc). When it comes time to calibration meetings, you’ll already have a deep awareness of who’s actually getting stuff done, and who is writing the quality code. You’ll see the technical leaders very visibly, including who is really setting the pace for the rest of the team (coding output, good feedback, work ethic, etc).

And from time to time, you may even find the opportunity to offer up a small suggestion yourself. Some might see this as micromanagement, however I’ve found that developers sincerely appreciate when their boss or boss’s boss or whatever really cares enough to take the time to understand their work at this level of detail.

There’s also the converse of this, which is that it helps to keep the team on its toes.

I even recommend that other developers on the team go out of their way to read code reviews and checkins in areas totally unrelated to their day jobs. This helps for the same reason it helps managers: you can learn from others, understand how the team operates and the expected level of output amongst different peer groups (or even those more senior than you), pick up tips and tricks, and so on. Even though I manage a group focused on a developer platform, you bet I go out of my way to read changes to device drivers, kernel, filesystem, networking, browser, etc. I always learn something new.

Now, of course, reading the code doesn’t tell you everything. It won’t give you a complete picture of the design and architecture. It won’t tell you who is going out of their way to collaborate with the team and helping others with their designs behind closed doors. It won’t always tell you who is not a team player (although more often than not it will). It won’t tell you whose code is most effective when it lands in the hands of customers. All of these things are critical, and must not become blind spots, so you’ll need to rely on other data points to supplement the code-oriented perspective.

But I really do believe that reading code is the most effective way to understand the inner workings of your team at a very intimate level. And hey, as the hair gets pointier over time, at least you can fantasize that it is you who is writing it ;-) So much code, so little time!